1. Field of the Invention
The present invention relates generally to a type of computer programming language which combines multiple programming paradigms (such as with object-oriented, functional, procedural), with a novel programming paradigm based on graph based dependencies (referred to as ‘associative’ programming). This type of language had been initially implemented or embodied in a language called DesignScript (DS). For the purpose of this patent application and without losing the generality, embodiments of the invention are embodied in the DesignScript programming language. Other programming languages may be utilized (with alternative semantics, syntax and execution). DesignScript, in addition to supporting generally accepted programming facilities and conventions, offers additional facilities not found in other programming languages, specifically a novel “associative” programming paradigm based on graph based dependencies as well as a unique relationship between the DesignScript language, the user interface, and user interaction.
At the semantic level, the facilities supported by the DesignScript language allows for the representation of data, logic and dependencies which offers advantages over conventional programming languages. Aspect of the invention relate to the way the language supports the representation of graph based dependency logic. Another aspect provides that the semantics used to represent the graph based dependency logic can also be combined with other semantics associated with object-oriented, functional, procedural and declarative programming paradigms to form an integrated programming environment. Further, this integrated programming environment (combining powerful aspects of one or more programming paradigm) conveniently allows different aspects of a single or group of related computational problems to be conveniently represented and executed as a single or related group of programs in novel ways not supported by existing programming languages.
At the syntactical level, the facilities supported by the language allow for a notation that is both more succinct than existing languages and also more understandable and accessible to both experienced and novice programmers. Alternative embodiments of this invention (for example, as implemented by other programming languages) may use different notation and syntax, but would allow for the representation and execution of the same logic and semantics that are at the core of this invention. An additional aspect of this invention is not just that the language supports the representation of graph based dependency logic but that the syntax can be combined with other syntax associated with procedural and declarative programming languages.
At the program execution level, the facilities supported by DesignScript language provide for a more efficient “graph based” propagation execution than is implemented in conventional programming language systems. A further aspect of this invention is not just the graph based execution but that this method of execution can be combined with other executions methods associated with procedural and declarative programming languages.
2. Description of the Related Art
Embodiments of the invention overcome many of the limitations of the currently available solutions. These current solutions are either other programming languages or other computer applications used in the design, analysis, simulation or optimization of artifacts or systems.
There are existing languages that combine object-orientation and procedural programming paradigms (e.g., C++, C#, Java™, etc). There are existing languages that combine procedural and logic programming paradigms (e.g., Poplog™ [http://en.wikipedia.org/wiki/Poplog]). There are existing data formats that allow for associative dependency relations to be defined (e.g., the GenerativeComponents™ data file allows dependencies to be defined in terms of “name-value pairs”, and Rhino Grasshopper™ uses XML [extensible markup language] file format). Both GenerativeComponent™ and Rhino Grasshopper™ have related procedural scripting functionality and also allow the use of externally defined procedural programming, via .net™ languages. In addition, existing applications (such as GenerativeComponents™) introduce the concept of “replication.”
However, while prior art existing languages and applications may provide useful functionality, it has many limitations. The limitations of the prior art are as follows:                The existing program languages (such as C++, C#, Java™), which support multiple programming paradigm, do not support the representation or execution of dependencies.        The data formats (such as GenerativeComponents™ and Rhino Grasshopper™), which do support the limited representation of dependencies, do not qualify as programming languages (for example these languages are not Turing-Complete).        In the context of the existing applications described above (which represent dependencies with data formats and rely on external procedural programming languages), the use of the combination of data format and programming languages has the limitation of forcing the user to use (and to learn how to use) many dissimilar languages and formats (one for dependency modeling and another for procedural programming).        The data format described above (such as GenerativeComponents™ and Rhino Grasshopper™), are verbose and are either awkward for the user to read and edit or are not designed to be human readable/editable. These limitations make it impossible for the user to understand the logic of his/her work in a convenient text notation.        While existing applications (such as GenerativeComponents™) may introduce the concept of “replication,” existing application do not provide suitable control facilities for replication above a 2D collection.        
In addition to the limitations described above, Rhino Grasshopper™ externalizes data using the standard formats such as XML. However, such externalization is no more than a serialization of the internal data structure. Further, the resulting data is so complex as to be effectively unreadable, let alone editable. For example, when complex data is recorded in the XML format, there is the need to maintain an exact pairing of the start and end delimiter tags. Any mistake in this matching would cause errors, but with such complex data, the “hand-editing” is likely to create such errors, therefore the prospect for such errors would inhibit the most hardened professional programmer, and would make a novice programmer shy away completely.
Further, the amount of the data used by GenerativeComponents™ and Rhino Grasshopper™ is excessive and cumbersome to create, view, and edit. In this regard, Tables 1 and 2 represent an example of a GenerativeComponents™ file and a partial RhinoGrasshopper™ file respectively, that both contain code that attempts to represent the same underlying geometric model, that of two points and a line drawn between these points. The GenerativeComponents™ file (Table 1) has 22 lines and is structured in name-value pair format. The RhinoGrasshopper™ file (e.g., partially illustrated in Table 2) has 239 lines and is structured in XML format.
TABLE 1transaction graphChange ‘Consolidation of 2 transactions’{ feature User.Objects.point_a Bentley.GC.Features.Point {  CoordinateSystem= baseCS;  XTranslation= 30.0;  YTranslation= 40.0;  ZTranslation= 0.0; } feature User.Objects.point_b Bently.GC.Features.Point {  CoordinateSystem= baseCS;  XTranslation= 10.0;  YTranslation= 10.0;  ZTranslation= 0.0; } feature User.Objects.myLine0001 User.myLine {  endPoint= point_a;  startPoint= point_c; }}
TABLE 2<?xml version=”1.0” encoding=”utf-8” standalone=”yes”<Archive name-“Root” > <!--Grasshopper archive--> <!--Grasshopper and GH.IO.dll are copyrighted by XXX --> <!--Archive generated by GH_IO.dll file utility library {0.1.0001}--> <!--Archive generated on Tuesday, 08 June 2010 10:03:23--> <items count=”2”>  <item name=“archiveVersion” type_name=”gh_version”   type_code=”80”>   <Major>0</Major>   <Minor>1</Minor>   <Revision>1</Revision>  </item>  <item name-“Created” type_name=”gh_date”   type_code=”8”>634116206036122368</item> </items> <chunks count=”1”>  <chunk name=“Definition”>   <items count=”1”>    <item name=“plugin_version” type_name=”gh_version”    type_code=”80”>     <Major>0</Major>     <Minor>6</Minor>     <Revision>59</Revision>    </item>   </items>   <chunks count=”3”>    <chunk name=“DefinitionHeader”>     <items count=”4”>      <item name=“HandleRhinoEvents” type_name=”gh_bool”       type_code=”1”>true</item>      <item name=“HandleHopperEvents” type_name=”gh_bool”       type_code=”1”>true</item>      <item name=“DocumentID” type_name=”gh_guid”       type_code=”9”>edd75b33-20aa-403e </item>      . . . .      . . . . . .
Therefore, there exists a need for a scripting language that can present a single consistent set of concepts, with a single syntax that addresses the full range of programming requirements. It must be clear, concise, and consistent. It must be easy to adopt and use by users with a broad range of conceptual knowledge and practical programming experience, bearing in mind that many of the users may not be professional programmers and that programming is not their main task but an aspect of some other professional tasks such as architectural design or structural engineering.